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Proc6d6 de charqement d'applications dans un svstfeme embarqu6 
multi-application muni de ressources de traitement de donn6es, 
svstfeme embarqu6 conrespondant et proc6d6 d'ex6cution d'une 
application d'un svstfeme embarqufe conrespondant 

5 La pr6sente invention conceme un proced6 de chargement 

d'applications dans un systfeme embarque multi-application muni d 
ressources de traitement de donnees, le systeme embarqufe correspondent, 
et le procedfe d'execution d'une application d'un systeme embarqu§ 
correspondant. 

10 La presente invention concerne plus particuliere la realisation de 

pare-feu entre modules partageant le meme espace memoire dans des 
systemes embarques sur des objets portables multi-application utilisant un 
pseudocode intermedia^ 

La technologie "Java" (marque deposee) introduite par la societe 

15 "Sun" est basee sur un langage de programmation orientfe objet "Java" et 
une machine virtuelle associee. Cette technologie a ete developpee sur des 
stations ou PC (Personal Computer), appelees ci-apres plate-forme "Java" 
classique. possedant une puissance CPU et une memoire importante de 
I'ordre du mega byte ou megaoctet. 

20 Depuis quelques annees, les concepts de la technologie "Java" ont 

fetfe repris et adaptes pour fonctionner sur des systemes embarques dans 
des objets portables, par exemple au format de carte de credit ou 
micromodule SIM incorporant un microprocesseur et appelee communement 
carte a puce, ou encore de telephones portables GSM (Global System for 

25 Mobile Communication), cartes PCMCIA ou tous autres terminaux portables. 
Par la suite nous utiliserons le terme carte pour designer Tun quelconque de 
ces objets portables. La programmation des systemes embarques. jusqu'ici 
realisee en assembleur. est dfesormais possible dans un langage evolu§ 
comme "Java", et permet de faciliter et d'accelerer le developpement 

30 d'applications clientes. 
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Ce nouveau type de plate-forme specifique aux systemes 
embarques d'un objet portable; app^ele ci-aprds"" plate-forme specifique, 
constitue un -sousrensemble^de^ia^plate^forme classique.^Les differences 
resultent du^^fait de renvironnememt reduit des -systemes«embarques. De 
5 maniSre^classique.-itjehique represemte^a la^ftgiire<i4a>kUr;ie>«Gant^ d puce (10) 
comprend un systeme d'entree et de sortie (11) relie au microprocesseur 
(14), une memoire volatile RAM (12) (Random Access Memory) une 
memoire non volatile constituee par une memoire morte ROM (13) (Read 
Only Memory) et une memoire non volatile programmable (15) constituee 

10 tfune flash RAM ou EEPROM (Electrically Erasable Programmable Read 
Only Memory), L'ensemble de ces elements est reli6 au microprocesseur par 
un BUSnde«iliaison9e^A titre»d*e$cemple«fefiune>«cart^ pueeMcomprend dans le 
meilleurs'^'^des" -ca53 en utilisant»--les nouveaux. composants actuellement 
existants,^ unerm^moire- R®M^.unei^imem0iriewEEPR©IVI^de -32 kilooctets ou 

15 kilo bytes, et'une>m§moire^RAM^deiiS^l!![i!@iB)Kesm 

DaTns^ un-systeme^ "ja^jraSHeiassique, stunewtappllcation est 6crite sur 
une ,stati0n**^ouNP©CS0ni>'code«ouircea*estiicompil6*d 
intermSdiaire, appele "Java Byte Code" ou byte code, qui est independent 
du code machine de la plate-forme utilisee. L'application est ensuite 

20 telechargee sur la plate-forme cible ou plate-forme "Java" classique. 
L'application chargee, constituee d'un ensemble de classes dites classes 
clients dont les methodes ont ete compilees dans le pseudocode, s'appuie 
sur les interfaces de programmation applicatives ou Interface pour la 
Programmation*' d'AppliGati0n>^ou«^API^(Applic&ti0n^^ 

25 Les interfaces de- programmation applicatives^- permettent- d'uniformiser 
IMnterfaGe*>utilisateur,« de controler^uin»=editetijr^^^^ 

par exemple. La machine virtuelle d'une plate-forme classique comprend un 
verifieur de pseudocode, un chargeur dynamique de classe, un interpreteur 
de pseudocode qui permet la traduction en code machine et un gestionnaire 
30 de securite. 
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La principale difference entre une machine virtuelle classique et une 
machine virtuelle d'un systeme embarqu6. appelee machine virtuelle 
specifique, est due au fait que la machine virtuelle d'un systeme embarquS 
est decomposee en deux parties separees. Suivant la figure 4b, la machine 

5 virtuelle comprend une partie (30) hors de la plate-forme sp6cifique (40), 
appelee machine virtuelle hors plate-forme ("off-platform"), comprenant un 
convertisseur (32), et une partie (41) dans la carte constituant la plate-forme 
specifique (40), appelee machine virtuelle embarquee (41) ("on-platform") 
incluant Tinterpreteur de pseudocode. 

10 Ainsi. dans le cas d'une plate-forme specifique, le programme 

source (21) de Tapplication est ecrit, compile en pseudocode intermediaire 
par un compilateur (22). et verifie par un verifieur (31) de pseudocode 
intermediaire sur une station (20) classique, puis converti par le 
convertisseur (32). place sur la meme station (20) ou une autre station. 

15 Apres un eventuel passage par un signeur (34). Tapplication est ensuite 
telechargee sur la memoire volatile programmable electriquement et 
eventuellement effagable electriquement EEPROM (15) de Tobjet portable 
ou plate-forme sp6cifique (40). Ce chargement est effectue par un chargeur 
comportant une partie hors plate-forme appelee telechargeur (33) et une 

20 partie sur la plate-forme specifique appelee chargeur (42). Contrairement a 
ce qui existe sur une plate-forme classique pour une station, la machine 
virtuelle (41) d'une plate-forme specifique (40), placee en memoire ROM 
avec le systeme Sexploitation (48) (Operating System) ne peut comporter de 
verifieur de pseudocode intermediaire, celui-ci etant trop lourd pour etre 

25 stock§ et/ou execute dans Tobjet portable. La plate-forme specifique (40) ne 
contient pas non plus de chargeur dynamique de classes. En effet. pour le 
domaine d'application de Tinvention. sur la machine virtuelle (30) hors plate- 
forme, le verifieur (31 ) verifie que les classes compilees sont bien form6es et 
verifie les violations de langage specifiques a la description de la plate- 

30 forme specifique. Le convertisseur (32) effectue le travail requis pour le 
chargement des classes et la resolution des references. Le convertisseur 
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effectue la liaison statique des classes, il resout les references symboliques 
aux classes, methodes et attributs deja presents sur la carte. II r^partit le 
stockagei^et cree les; structures des-donnees pour«irepresenter les classes, 
cree les methodes et attnibuts statiques ou natifs et^^initialise les variables 
5 statiqwesti^, 

L'environnement d'execution de la plate-forme specifique (Runtime 
Environment ou RE) comprend la machine virtuelle embarqu6e ("on- 
platform") (41) se limitant a un interpreteur. une plate-forme API et les 
methodes dites natives (43) ou encore statiques associees. La plate-forme 

10 API comprend les API (44) (Application Programming Interface) definissant 
un ensemble de classes, dites classes systeme (45), et les conventions 
d'appel**par lesquelles une application accede a Tenvironnement d'ex§cution 
(RE) et aux methodes statiques (43). Les methodes statiques (43) executent 
les services d'allocatipn de memoire. d'entree et sortie, et cryptographique 

15 de la carte. 

L'interpreteur^de la machine virtuelle«embarquee de la carte (41 )(on- 
platform). sert de-support au langage "Java", et lit de- fagon-sequentielle le 
pseudocode intermediaire, instruction par instruction. Cheque instruction 
standard de ce pseudocode intermediaire est interpr6tee dans le langage du 

20 microprocesseur par I'interpreteur puis executee par le microprocesseur. En 
regie generale, les instructions standards du pseudocode intermediaire 
permettent de traiter des fonctions evoluees telle que le traitement 
arithmetique et la manipulations d'objets. La notion d'objet conceme les 
objets informatiques tels que listes, tableaux de donnees^ou analogues. Les 

25 classes dites clients (46) des applications et les classes systemes (45) des 
API sont toutes chargees dans le meme espaee mermoire^et sont g6rees par 
rintermediaire d'une table de classe (47). 

La machine virtuelle (41) est egalement chargee de gerer les 
classes et objets et de faire respecter les separations ou pare-feu entre les 

30 applications afin de permettre un partage securise des donnees, appelees 
egalement attributs, variables ou champs (fields). 
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Dans le cas d'un objet portable de type carte a puce, une application 
d'une plate-forme specifique peut etre activee directement par 
Tenvironnement d'execution (RE) lorsqu'une APDU (Application Protocol 
Data Unit) de selection emise par un service ou terminal est regue par la 
5 carte. 

Afin de restreindre Tacces aux donnees entre les parties de code 
partageant le meme espace memoire, une des mSthodes classiques sur une 
plate-forme classique est basee sur la restriction explicite de visibilite 
declaree dans le code source. Suivant la figure 4c. les methodes (NM1. 

10 NM2), respectivement (NM3. NM4), et les attributs (NA1, NA2), 
respectivement (NA3, NA4) sont encapsulees dans des classes (NCI3), 
respectivement (NCI2). qui elles-memes font partie de paquetages 
(Paquetage 1), respectivement (Paquetage n) regroupant chacun plusieurs 
classes. Une classe peut §tre publique telle que (NCl1 ou NCI2) ou priv6e 

15 telle que (NCI3) par rapport a un paquetage, ce qui implique, dans le dernier 
cas, que seules les classes du meme paquetage peuvent acceder a cette 
classe. Les methodes (exemple NM2) et les donnees (exemple NA1) d'une 
classe (NCI3) peuvent §tre privees par rapport a la classe (NM2, NA1). qui 
elle-mfeme est privee par rapport au paquetage (Paquetage 1), ou publiques 

20 par rapport au paquetage (par exemple NM1. NA2) ou a la classe (par 
exemple NM4, NA4). Cette restriction de la visibilite permet d'obtenir un 
acces flexible entre les differents ensembles de paquetages (Paquetage 1 , 
Paquetage n) slockes dans le meme espace nom. mais presente quelques 
inconvenients. La plate-forme classique ou specifique supporte mal la notion 

25 de sous-paquetages. Les classes client d*une application de grande taille 
doivent etre reparties entre diff§rents sous-paquetages qui representent 
uniquement pour la machine virtuelle des paquetages diff§rents. Pour 
partager les ressources entre ces sous-paquetages, ces ressources sont 
necessairement deciarees publiques. les rendant ainsi visibles de tout autre 

30 paquetage, II est ainsi difficile d'organiser de fapon claire le paquetage 
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d'applications differentes pour des applications de grande taille et d'obtenir 
des pare-feu entr^ les applications. 

Dar)s*ile cas de la plate^forme classique, sur une«rStation^ le respect 
de la confidentialite des*ressources, telie^que dedaree dans^les programmes 

5 sources, repose sur- des« ve^ifications-^vdynamiques^^ P6ur- effectuer ces 
verifications dynamiques, la machine virtuelle doit posseder toutes les 
informations concernant les declarations de restriction d'acces pour chaque 
classe. methode ou atthbut, ce qui ne peut etre possible dans le cas de 
I'espace memoire disponible sur la machine virtuelle embarquee 

10 (onplatform) utilisant le pseudocode intermediaire ou byte code preli6 de la 
machine virtuelle hors plate-forme (offplatform). Dans le cas d'une plate- 
forme«wspe6ifiqute>4d'un»'<©bjet«r«porftable<»«kl^ peuvent se 

verifieV statiquemernt^lors - de^iatucompilation-^et peuvent*^r§tre verifi6es d 
nouveau^par^le^verifieur de^^la .partiefhors^plate^forme. II est en effet suppos6 

15 que ce-«quijnest«eharg6j?tSur#la'''plate-forme«ped^ portable est 

correct?? car.^auGunes»*verifig&tion ne^^peut etre^ effectuee^sur la plate-forme 
specifique*^du*fefait«i?de>«ilasttpej<e^ phase de 

conversion. De plus il n'est pas garanti qu'un paquetage ne puisse pas etre 
etendu ou modifie par de nouvelles classes venant de sources etrangeres, 

20 ce qui peut detruire toute la securite basee sur Tutilisation de paquetages 
prives. 

Le deuxieme moyen procure par la machine virtuelle d'une plate- 
forme classique est la notion de separation des espaces nom. Avec le 
scherna«jdeHials0n**^dynamique ^d'iane**plate-forme^ classiqiue?* les classes 
25 peuvent §tre chargees. a partir de repertoires du systeme de^fichier local, 
appeld«iiCllrssBathi^preaiablement ddelare«(^ 

des classes systemes formant la plate-forme API standard, ou a partir 
d'autres repertoires du systeme de fichier local ou de serveurs eloignes. Les 
classes client d'une application, exterieures au "ClassPath", doivent etre 
30 chargees par un chargeur de classe specifiquement programme. Cette 
caracteristique est particulierement utilise pour le chargement des 
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applications "Java" par des navigateurs habilites "Java". Ainsi. les 
applications venant de differentes sources, sont chargees par des chargeurs 
de classes differents. Pour chaque localisateur, communement appele URL 
(Uniform Resource Locator), une instance specifique de classe "chargeur de 
5 classe d*application" est utilisee. Le nom externe d'une classe est 
Tassemblage <Nom Du Paquetage > + <Nom De La Classe>. Quand une 
classe est chargee, elle est stockee dans une table de classe interne, et une 
reference relative au chargeur de classe utilise pour charger cette classe est 
ajoutee en prefixe du nom de paquetage de la classe. Le nom de la classe 
10 est alors «Reference du Chargeur de Classe> + <Nom Du Paquetage> + 
<Nom De La Classe». Ainsi des classes declarees comme appartenant au 
meme paquetage mais chargees par des chargeurs de classes diff6rents ne 
sont pas pergues par la machine virtuelle comme appartenant au meme 
paquetage. 

15 Lors de la resolution d'une reference, la politique habituelle des 

chargeurs de classe est de rechercher d'abord dans les classes systeme et 
en cas d'echec. de rechercher parmi les fichiers de classe pr6sents a 
{'emplacement ou le chargeur peut charger les classes. Selon ce principe de 
fonctionnement du chargeur, une application ne peut directement acceder ' 

20 aux classes clients d'une autre application chargSe par un chargeur de 
classes different. Une application peut acceder a toutes les ressources 
publiques des classes publiques du ClassPath, mais les classes du 
ClassPath ne peuvent acceder directement aux classes d'une application 
bien qu'elles puissent faire reference a des instances de classes clients de 

25 I'application en les convertissant en un type public defini dans le 
"Classpath". Une application ne peut etendre ou modifier des paquetages de 
classes systeme du Classpath ou de toutes autres applications chargees par 
des chargeurs de classes differents. Lutilisation de la separation des 
espaces nom en inserant une reference du chargeur de classe dans le nom 

30 de la classe, ajoutee au typage complet fourni par le langage "Java", permet 
de procurer un pare-feu efficace entre les applications. Le mecanisme inne 
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de separation de nom d'espace permet facilement le chargement de 
nouvelles- applications. 'Les applie^tions-^peuvent echanger*^es objets par 
rentPemise* desw classes- speGifiquemenit**?'prL0griapnrnees>^a cette fin et 
localiseesidans leiSiCiasspath". Une appliGation*tpeut utifi^p^un objet venant 

5 d'une autre^application^^GhargeeMpar uniiehargqwrsitde^c^ si cet 

objet peut etre change en un type public defini dans le "Classpath". 

Malheureusement ce mecanisme de separation de nom, bas§ sur 
une machine virtuelle classique et son processus de liaison dynamique ne 
peut etre effectue sur une plate-forme specifique. La liaison dynamique ne 

10 peut etre effectuee par la machine virtuelle d'une plate fomie specifique, 
celle-ci necessitant un espace memoire permettant le stockage de fichier de 
classejiid*ume«plate3f0rime^Ja>^a«kclassiqui^^^^ non 
resoluesr«Dans^une«<plate^forime^speeifr^ia^^ des API et 

les classesjclients des^appjieationswroetfsont pasviso^^^^ des espaces 

15 de nommagf*partiGUjjiertSfi» — 
L'obje,t^de^la^pregfeinte1i|inventi0n^^^ une solution 

procujramt«lesiavari)tag0S;»deiila*sep;a/rati©R^^ de systemes 

embarques possedant une machine virtuelle en deux parties, le schema dei 
liaison statique etant effectue par la partie hors plate-forme. 

20 Dans le contexte de systemes embarques, tels que par exemple les 

terminaux de paiement. multi-application, il est necessaire d'avoir des pare- 
feu performants entre les applications "Java" fournies par differentes 
sources, telles que differents systemes de paiement (Visa, Mastercard...). II 
peut etPe^utiiewde^permettreiiiujne^eoopepatiGn'-fle^ib^ 

25 venant des differentes sources. Le ^systeme embanque'^doit aussi §tre 
facilememt*^mis??^a^jQiuri»enKeleGhang©,aint^de^ ou de 

nouveaux modules utilitaires ou encore des mises a jour sans perturber les 
applications deja chargees. 

Un premier but de Tinvention est de propos r un precede de 

30 chargement permettant d'obtenir des pare-feu robustes entre les 
applications tout en autorisant une cooperation entre les applications et la 
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possibility de faire evoluer les applications ou de charger d'autres 
applications. 

Ce but est atteint par le fait que le proc§dd de chargement 
tfapplications sur un systfeme embarque selon invention, comprenant un 
5 environnement d'execution incluant una machine virtueile comprenant un 
interpr^teur de langage de type pseudocode intermediaire, des interfaces de 
programmation d'application (API), a partir d'une station sur laquelle le code 
source de Tapplication est ecrit, compile en pseudocode par un compilateur , 
verifi6 par un verificateur. converti par un convertisseur et charge par un 
10 chargeur, se caracterise en ce que 

- la conversion comprend la realisation de ta liaison statique d'une 
plurality d'ensembles de paquetages destines S §tre stock^s dans le m&me 
espace nom sur le systeme embarqu^, appeles modules, en attribuant un 
identificateur a chaque module (MID), et un numero de r6ferenee^ cheque 

15 classe, d chaque m§thode et d chaque attribut encapsuISs dans les classes 
du module, 

- la reference a une methode ou un attribut, dans le pseudocode liS 
d*un module, etant codee sur trois multtplets constituSs par un indicateur 
indiquant la reference a une classe inteme ou exteme au module, le num6ro 

20 de la classe et soit le numero de la methode soit le numero de I'attribut, 

- les modules charges sont un ou plusieurs modules d'interface de 
programmation d'application, appele Module API, comprenant des classes 
systeme ou des modules de services correspondent chacun a une 
application, une reference d une classe externe etant systematiquement 

25 interpretee par la machine virtueile comme une reference a un module 

d'interface de programmation d'application. 

Selon une autre particularite, le chargement des modules sur le 

systeme embarque comprend la memorisation d'une part d'au moins un 

tabi au de representation des modules, le numero associS, par I lieur 
30 compris entre 0 et n, d un module constituent I'index dudit module dans I 

tableau, et d'autre part d'une table memorisant I'association de I'index du 
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tableau de representation a ridentificateur (MID) dudit module, ledit tableau 
et la table etant en memoire programmable non volatile, une reference 
externe a un module exteme dans le pseudocode .6tant interpret6e par 
I'interpreteur de la machine virtuelle comme constituant^un index d'acces au 

5 module equivalent a celui du tableau des^modules.^. 

Selon une autre particularity, le chargement comprend la 
memorisation, pour chaque module, d'un tableau de repr§sentation de ses 
classes, comprenant une reference a Tindex de son module et, pour chaque 
classe. un tableau de representation des attributs et des methodes. 

10 Selon une autre particularite. les modules sent references dans un 

tableau de modules unique, les classes systeme sont contenues dans un 
module API unique, toute*^ ref6renee^ a^ une*^ classe exteme dans le 
pseudocode diff6rente de n sera interpretee par la machine virtuelle comme 
une reference audit module APIf 

15 Selon une-autre particularite, les classes^^tant declarees publiques, 

ou en paquetage prive, les attributs et methodes 6tant d§clar6s proteges, en 
paquetage priv6e : oa^ en classe'^^priv6e, la . numerotation des classes 
s'effectue suivant Tordre classes publiques puis classes en paquetages 
priv6s, la numerotation des attributs ou methodes est effectu6e par le 

20 convertisseur suivant I'ordre attribut ou methode public, protege, en 
paquetage prive et en classe privee. 

Selon une autre particularite. les classes systeme sont contenues 
dans plusieurs modules API chargeables separement, le chargeur maintient 
dans la memoire non volatile programmable deux tableaux de representation 

25 des modules et deux tables d'association MID/IMi correspondantes. Tun pour 
les modules API et^l'autre pour lestmodules non-API. le chargeur chargeant 
les modules dans Tun des deux tableaux selon la nature du module sp§cifi§ 
dans Tentete de celui-ci, toute reference exteme d'un module du tableau de 
module etant interpretee comme une reference a I'index du module API. 

30 Selon une autre particularite. la liaison statique d'un module est 

effectuee de telle sorte que la reference a une classe externe a un module 
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non API dans le pseudocode intermediaire est un index dans un tableau de 
Tentete du module, dont chaque entree est un identificateur (MID) d'un 
module API r^f^renc^, le chargement dudit module sur la plate-forme cible 
comprenant le remplacement de iadite reference par ie numero de i'index 
5 du module API obtenu a partir de T identificateur (MID) de ia table 
d'association des modules API. 

Un autre but de I'invention est de proposer un systdme embarqu§ 
correspondant. 

Ce but est atteint par le fait que le systems embarque selon 

10 I'invention, comprenant une machine virtuelle et une plate-forme API 
incluant des interfaces de programmation d'application. une memoire non 
volatile fixe, une memoire non volatile programmable ou modifiable, et une 
memoire vive, se caracterise en ce que la m6moire non volatile 
programmable comprend au mbihs un mddijie API comprenant des classes 

15 syst§me et des modules de services, au moins un tableau de representation 
des modules, dans lequel les modules sont indexes et une table associant 
I'index d'un module du tableau de representation ^ r identificateur dudit 
module, chaque module comprenant un tableau de representation des 
classes, dans lequel les classes sont indexees et dans lequel chaque classe 

20 presente une reference S Tindex de son module, chaque classe comprenant 
un tableau de representation des attributs et des methodes, dans lesquels 
les attributs et m6thodes sont indexes, la reference a une m6thode ou un 
attribut etant codee sur au moins trois multiplets correspondant a une 
reference a une classe interne ou externe au module, une reference externe 

25 au module constituant I'index du module API dans le tableau de module, un 
num6ro de classe correspondant a I'index de la classe dans la table de 
representation des classes du module, et un num§ro de m6thode ou 
d'attribut correspondant a I'index de la methode ou de I'attribut dans le 
tableau de representation des methodes ou attributs d la classe du module. 

30 Selon une autre particularit6. le systeme embarqu6 comporte des 

moyens de comparaison du premier multiplet des trois multiplets de codage 
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de reference a une methode ou a un attribut avec une valeur determinee n 
pour decider s'il s'agit d'une classe interne ou externe. 

Selon une autre particularite, le systeme embarqu6 comprend un 
module principal comprenant le programme principal du systfeme. 

5 Selon une autre particularite, les classes sont index6es suivant 

I'ordre classes publiques puis classes en paquetages prives, et les attributs 
ou methodes suivant Tordre attribut ou methode public. proteg6, en 
paquetage prive et en classe privee, 

Selon une autre particularite, la memoire non volatile programmable 

10 comprend plusieurs modules API comprenant des classes syst§me, deux 
tableaux de representation des modules. Tun pour les modules API et I'autre 
pour les modules^ non-API et le module principal, et deux tables 
d'association MID/IMi correspondant chacune a un tableau de 
representation des modules , 

15 Selon une autre particularity; le systeme embarqu6 comprend une 

classe gestionnaire d'acces "Access manager" d'un module API comprenant 
une m6thode permettant de creer une instance d'un module de service, par 
I'intermedlaire du module principal, ladite classe presentant une protection 
lui interdisant d'avoir plus d'une instance. 

20 Un autre but de I'lnvention est de proposer un precede d'execution 

d'une application presente sur un systeme embarque multi-application. 

Ce but est atteint par le fait que le precede d'execution d'une 
application d'un systeme embarque multi-application, comprenant un 
environnement execution incluant une machine virtuelle comprenant un 

25 interpreteur de langage de type pseudocode intermediaire, et des interfaces 
de programmation d'applications (API), se caract6rise en ce que, lors de 
rexecution du pseudocode intermediaire d'un module de service, 
correspondant a une application, referencee dans un tableau de module, la 
reference a une method ou un attribut dans le pseudocode, codee sur au 

30 moins trois multiplets correspondant a une reference a une classe interne 
ou externe au module, un numero de classe et un numero de methode ou 
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d'attribut, une reference externe au module est interpr6tee par la machine 
virtuelle cbmme une reference a Tindex d'un module API du tableau du ou 
des modules API. 

Selon une autre particularit6, sur reception d'une demande 
5 d'exScution d'un module de service presentant un identificateur, 
I'environnement d'ex^cution accdde a la classe d'entr§e d'un modul 
principal comprenant le programme principal du systeme, le module principal 
installe une instance d'une classe speciale "Access Manager", d'un module 
API. gerant I'acces a un module de service et utilise une methode de cette 
10 classe permettant de creer une instance de la classe d'entree du module d 
service demand^e, par I'intermediaire d'une table d'association de 
r identificateur a I'index du module dans un tableau dans lequel le module 
est reference. I'lnstance etant retournee par la methode au programm 
principal. 

15 D'autres particularites et avantages de la presente invention 

apparaitront plus clairement a la lecture de la description ci-apr^s faite en 
reference aux dessins annexes dans lesquels : 

- la figure 1 represente de fagon schematique les differents § laments 
n^cessaires pour le chargement d'un objet portable selon un premier mode 

20 de realisation ; 

- la figure 2 represente de fa^on schematique les differents elements 
necessaires pour le chargement d'un objet portable selon un deuxidme 
mode de realisation ; 

- la figure 3 represente la representation inteme d'un module ; 

25 - la figure 4a represente le schema classique d'une carte d puce ; 

- la figure 4b represente le systeme n^cessaire a la constitution 
d'une machine virtuelle embarqu^e sur une carte a puce selon I'art anterieur; 

- la figure 4c represente la structure des classes d'une application. 
Le precede sera decrit. en liaison avec les figures 1 d 3. de mani§r 

30 non limitative, dans le cas de la mise en oeuvre de I'invention dans un 
systdme embarque, par exemple de type sp^cifique constituS par une carte 
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a puce ou un objet portable similaire. La designation byte code ou 
programme de type byte code recouvre tout pseudocode ou programme 
intermediaire. 

L'objet portable^constitue par exemple*une*carte-^ puce et pr§sente 
5 une strueture^similalne^de ^.celle^ deGnite)ypreGedemmemt9ieniHtref6rence aux 
figures 4a et 4b. et comprend notamment une memoire RAM, ROM et 
EEPROM. La plate-forme specifique (60) et une station classique (80) sont 
representees sur la figure 1. La plate-forme specifique (60) possede en 
ROM. un environnement d'execution (RE) comprenant des API (62) et une 
10 machine virtuelle (61) embarquee ("onplatform"). La plate-forme sp6cifique 
(60) est representee sur la figure 1. comme comprenant Tensemble des 
memoires£R©M»et*EeEfR©M*ll esttS moter^que^la-^platerforme sp6cifique (60) 
designer pl^s^partieuilidrement^renvironnement^ d'execution (RE) et les 
elements presents en memoire EEPROM.^ Uobjet portable possdde en ROM 
15 un systdme d'expioitationKOperatingii^ystem)' (63)^Les*API (62), presentes 
en memoire*KR©M|»rconstitiuent'^les -API?*de base^de la plate-forme API. 
chargees».iaveG*^la^maGhine%virtiyelle~iembarquee«pQuir^ie fonctionnement de 

celle-ci 

La partie (90) hors objet portable de la machine virtuelle comprend 
20 un verifieur (91) de pseudocode intermediaire. un convertisseur (92) et 
eventuellement un signeur (94). Le signeur delivre une signature pour 
valider le passage par le verifieur et le convertisseur. Cette signature sera 
verifiee par Tobjet portable au moment du chargement. Le chargement en 
EEPROM d'appliGati©ns«ou de nouvelles*API pour compl6t6r'^ base 
25 s'effectue par un chargeur qui peut etre compose de deux parties, une partie 
hors objet^-portable*ipQiiivanfe etre^installee dans Ma^maehine- virtuelle hors 
objet portable (90»)r^appelee telechargeur (93>)?i et une partie sur la plate- 
forme specifique, appelee chargeur (68). 

Selon un premier mode de realisation, la plate-forme specifique (60) 
30 comprend deux modules speciaux. un module API (65) et un module 
principal (66). Les autres modules sont appeles modules de services (67). 
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Chaque module correspond a un ensemble de paquetages qui sera stock§ 
dans le meme espace nom. La plate forme API designe les API de base (62) 
et Tensemble des classes systeme qui definissent le module API (65) ou 
module de la plate-forme API. Le module principal comprend la classe 

5 principale definissant le programme principal. Chaque module, excepte le 
module API (65). possede une classe unique, particulidre, appel6e "Entry 
Class", qui constitue le point d'acces au module. Pour le module principal, 
cette "Entry Class" est la classe principale (CP), celle qui contient une 
methode statique appelee "main". Pour les modules de services, c'est une 

10 classe avec seulement un constructeur sans paramfetres et impl6mentant 
une interface publique speciale, appelee "service" d6finie dans la plate- 
forme API, Le chargement d'une application correspond au chargement d'un 
module de service. Chaque module revolt un identificateur sp§cifique. Un tel 
identificateur, qui est appele MID. peut par exemple §tre un nombre, une 

15 chaine de caracteres, ou un tableau. A titre d'exemple, Tidentificateur est 
une chaine de caracteres. 

Quand ils sont charges dans la plate-forme, par des mecanismes de 
telechargement distincts de la machine virtuelle de la plate-forme sp6cifique, 
les modules re9oivent un nombre, compris entre 0 et n. Ainsi. selon cette 

20 convention, n+1 modules au plus peuvent etre presents sur la plate-forme 
specifique. Le telechargeur (93) de module avec le chargeur (68) maintient, 
lors du chargement de nouveaux modules de service, un tableau (TRM) (69) 
de representation des modules. Le numero associe d un module est Tindex 
(IM) de ce module dans le tableau. Le chargeur (68) maintient egalement 

25 une table (70) associant Tindex (IM) a r identificateur (MID) de chaque 
module. Le module API regoit systematiquement pour index IMo le numero 0, 
et le module principal pour index IMi le numero 1. L'entete (header) de 
chaque module comprend un indicateur permettant au chargeur de 
determiner la nature du module, "principal", modules "de service" ou module 

30 "API". 
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Le chargeur (68) ne peut charger que les modules autorises a 
resider sur robjet portable; fc'est a dire uniquement les modules presentant 
une sigmatujFeMConnue'4deHl.*objet«'portabler Le chargejjr^(6&)KDomporte done 
des moyenis*de verifreY- la signaturie*d'unrmoduIe-re§u;*de»la^comparer avec 
5 la signature' (X}mRue^de I'objetiNportableMet eri casmdeviGornp^ negative 
de bloquer le chargement. 

De maniere classique, tel que defini dans Tart ant6rieur cit6 
precedemment, le programme source (81) d'une application est ecrit puis 
compile par un compilateur (82) et ensuite verifie par le verifieur (91). 
10 La liaison statique, realisee dans le convertisseur (92) par un 

composant dit lieur (linker) du convertisseur. va resoudre des references 
symbol iquesienrattribiltanit«^ 

- un numeF0<N©l) a chaqus^Glasse d'un modulejfc 

- un- numeTO-(NMi)3pQurjchaquJ,e*rfmetbode danssune elas et 
15 - un«numero«(fN^)iipoi£iniehaque/attnibi£it dans'-^iunevclasse. 

Chacun de ces^numeros (NCI. NM. NA) est-compris entre 0 et n et 
peut aimsi»etrei^Fepresente^si!iriiurns>byteiioutmultiplet. A titfe*td'6xemple, chacun 
de ces nombres sera compris entre 0 et 255 (n=255). La reference a une 
methode ou un attribut d'une classe sera ainsi codee dans le pseudocode lie 

20 des methodes du module sur deux multiplets (bytes) ou octets. Le 
pseudocode contiendra ces deux multiplets < NCI> pour la classe et < NA> 
pour un attribut ou <NM> pour une methode. 

Suivant la figure 3. la representation interne d'un module API (65), 
d'un module^^prineipal*(66t tJUMd'uh^modiule ^de-^serviee^ (67^^^ contiendra un 

25 tableau (TRC) de representation de classes ; le numero (N©l) associe par le 
lieurr hons du*^*sy^t6pneMembarque^a chaque;aclasses^4est<«rindex (ICi) de la 
representation de cette classe dans le tableau (TRC)y Chaque classe 
presente egalement une reference a Tindex (IMi) de son module. De la 
meme maniere, la representation de chaque classe contient un tableau des 

30 representations de methodes (TRMe) et un tableau de representation des 
attributs (TRA) appartenant a la classe. Le numero (NM). associe par le 
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lieur, hors du systeme embarque. a chaque methode est Tindex (IMi). de la 
representation de cette methode dans le tableau (TRMe). et le num6ro (NA). 
assocle par le lieur, hors du systeme embarque, a chaque attribut est {'index 
(lAi), de la representation de cet attribut dans le tableau (TRA). 

5 A titre d'exemple, nous voulons qu*un module puisse ref^rer 

uniquement a ses propres classes et aux classes systdmes de la plate-forme 
API, les classes systeme correspondant aux classes du "ClassPath" d'une 
plate-forme classique. Selon invention, pour permettre la distinction entre 
une reference a une classe interne au module et la reference a une classe 

10 systeme (ou externe au module), un indicateur interne (II) ou externe (IE) est 
ajout6 a la reference a une methode ou a un attribut. La reference resolue 
est alors codee sur trois multiplets : <IE/ll> <NCI> < NM> ou <IE/II> <NCI> 
<NA> 

Selon une convention posee, pour la valeur n du premier multiplet 
15 <IE/II> la valeur 255 d'apres notre exemple, correspond a une reference 

interne <ll> au module et toute autre valeur pour le premier multiplet 

correspond a une reference externe <IE> au module. 

Le lieur du convertisseur (92) de la machine virtuelle hors objet 

portable (90). relie en premier le module API (65), qui ne possede pas de 
20 r6f6rences externes <IE> dans son pseudocode, et produit une implantation 

ou agencement, correspondant a un plan de noms symboliques de ses 

classes et de leurs methodes et attributs. Lors de la mise en liaison des 

autres modules, cette implantation sera utilisee pour 6tablir les references 

externes a des classes systemes du module API (65). 
25 Suivant notre convention des multiplets (bytes) encodant les 

references, il peut y avoir au plus 256 (n+1) classes dans le module API et 

256 classes dans chaque module supplementaire. 

Lors de {'execution d'un module de service, quand la machine 

virtuelle (61) trouve une reference a une methode <NM> ou un attribut <NA> 
30 dans le pseudocode, en connaissant la classe <NCI> ou se trouve cette 

reference, elle peut retrouver directement Tindex <IMi> du module concerne, 
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celui-ci correspondant a la reference externe (IE) ou interne (II). Toute 
reference exteme <IE>*danS le pseudo-^code-'d'un module de service sera 
systematiquemernfainteppretee par-^la mad^ine*virtuelle¥Gom 
au module^API. Un jrioduie de-service ou' le^moduteiiprincl pas 

5 ref6rer-*aux^Glasses*de4Dut*autre-m0djLjle*exeept^^ Les 
classes systemes de ce module API ne peuvent pas referer aux classes d'un 
module de service ou du module principal. La reference interne a une classe 
d'un module, correspondant a la valeur n pour le premier multiplet, ne 
necessite aucune connaissance a priori de i'espace nom qui sera attribue au 

10 module. Le fait de ne pas definir a priori d'espace de nommage fixe lors de 
la phase de conversion permet d'accelerer la resolution des references et de 
determiner^TespaGejiBdeMnommag^d'unr^mGdiulejiiEloR^^ chargement, 
posterieiarement a ila phase de^ponversion. La imachiRe«*virtuelle, lors de 
rinterpr^tation d*une<^referienice^a iUn«attnibujtaouHia4une«tm§thode dans le 

15 pseudocGde?iiutilis^iiles-trois«index4fcs=IB/U2^<N®^ <NCI> 
<NA>^en'^casGade5^L'espace^memoineN^du?^im©dule^etant'«^determlne Tindex 
<NCI> 'd§termine«|2€htr§e^dei5ireevdams9^le^^^ (TRM) du 

module, puis le dernier index < NM> ou <NA> donne Tentree desir6e dans le 
tableau des methodes (TRMe) ou le tableau des attributs (TRA). 

20 Le module API comprend une classe speciale (64), appelee classe 

"gestionnaire d'acces" ou "Access Manager", qui comprend une methode 
native (getServicelnstance) dont le role est de rendre un objet instance de la 
classe d'entree du module de service demande. a partir de Tidentificateur 
(MID) du moduile*»Cette^meth0de»ititilis^eHa table-(70)^d*assGciation MID/lmi 

25 pour connattre IMndexidu module demande dans le tableau de module (69) 
puis cr6e une instameeijde^la classei^d'entree-de)ftcej^modisile]*instance qui est 
retournee par la methode. Selon Tinvention la classe "Access Manager" (64) 
est protegee par construction par une methode consistant a interdire que 
cette classe ait plus d'une instance. Cette methode (getServicelnstance) 

30 appartient au programme principal contenu dans le module principal. Le 
module principal qui sera active en premier a utilisation de I'objet portable 
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cree une instance et une seule de la classe "Access Manager", ce qui lui 
pemnet d'utiliser la methode getServicelnstance, mais interdit a tout autre 
service de cr^er une autre instance pour utiliser cette methode. 

En fonctionnement. • de la meme fa9on que sur une plate-forme 
5 classique, I'environnement d*ex§cution (RE) accede d la classe d'entr§e 
(EC) du module principal et active sa methode d'entree (main). Le module 
principal, etant le premier active, precede a I'installation d'une instance de la 
classe "Access manager" avant que tout autre service le fasse, puisque pour 
activer d*autres services, le module principal doit deja posseder une telle 

10 instance de la classe acces. 

Ce simple dispositif permet de reproduire I'effet de protection lie au 
concept d'espace de nommage d*une plate-forme classique. Le simple fait 
de charger un module de service dans le tableau des modules et que la 
presence dans le pseudocode de toutes reference externe soit interpretee 

15 par la machine virtuelle comme une reference au module API, rend ce 
module completement inaccessible directement par les autres modules, 
creant ainsi un pare-feu total. 

Ce premier mode de realisation permet d'apporter les a vantages de 
pare-feu procure par la separation des espaces nom dans le contexte d'une 

20 machine virtuelle en deux parties. Toutefois ce mode de realisation se revele 
peu flexible et presente deux inconvenients. 

Premierement, 11 empeche toute modification ou extension des 
classes systemes avec des modules deja prelies. Une architecture "Java" 
classique permet de modifier et d*etendre les classes de la plate-forme API 

25 sans avoir d'impact sur les classes dejS compilees de modules 
supplementaires. Mais dans le mode de realisation decrit pr§c§demment, 
toute modification des classes systeme, meme invisible pour des modules 
etrangers, modifierait I'agencement de la plate-forme API et n^cessiterait de 
modifier le pseudocode preli ' de chaque modul dej^ lid avec une version 

30 anterieure de Tagencement et en consequence Tinterpreteur. 
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Deuxiemement, les modules prelies sont supposes etre portables 
entre les differentes plates4ormes-ou terfninaux embarques. ce qui impose 
que chaeune^ de«iGes>qplates^fonmesr^dojfr avoir^^^ que la 

plate-fG)fme-API?Ge:quiMnterdit rutilisation de touteiextenslGmiproprietaire. 
5 Aftn*de«rtemedienipartiellement#a QesBint^rav^^^ du 

premier mode de realisation, consiste a imposer que, dans la num6rotatlon 
de rimplantation. les classes publiques viennent en premier avant les 
classes en paquetage prive. De plus, les methodes publiques ou les attributs 
publics viennent avant ceux qui sont proteges et ceux qui sont en 
10 paquetages prives et en classes privees. Ceci permet d'ajouter librement de 
nouvelles classes publiques dans le module API (65). 

La>figjij5ej2^fiepriesernte*un»i^ 
revolution ^dewla^plate-forme^nARIIi^La platerforme API^est^^constituee de 
plusieuns^modules^ARIKI OQ)-'^P©wv.ant^e au lieu 

15 d'etre^constitajeeid'ufrnjmadul^^^ 

Dans ce^«mode**de*realissti0fn?^le ^teleehargeur (93)%et la machine 
virtuelle»<partag^mt«deux4ableau3s;^de^m0dulesmet<ideiux^^^ d'association 
MID/index au lieu tfun de chaque. un tableau (101) et une table 
d'association (102) pour les modules API et un tableau (103) et une table 
20 d'association (104) pour les modules non-API, correspondant au module de 
service (67) et au module principal (66). 

Chaque module presente dans son entete un indicateur indiquant sa 
nature "Service" ou "API" permettant au chargeur de charger le module dans 
le tableau (101 )^de^m0duIes API^uiidans-le tableau»(103)^de^modules non- 
25 API. Get indicateur est place dansH'entete du module lors^de la phase de 
compilati©n«par«le*GonyertisseuiPiy#t 

Le pare-feu constitue par la separation de Tespace nom est present 
uniquement entre les modules non-API. Toute reference exteme a un 
module de service sera interpretee par Tinterpreteur de la machine virtuelle 
30 embarquee comma un index du tableau du module API. 
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Les modules non-API seront numerotes de 0 jusqu'a 255 au plus, 
dans Texemple ou n=255. 0 est par exemple Tindex du module principal (66). 
Les modules API (100) seront numerotes de 0 ^ 254 au plus, 0 §tant par 
exemple Tindex d'un module dit API primaire, qui contient toutes les 
5 methodes natives. Conform6ment a la convention decrite pr6c6demment, 
ceci permet au plus. 256 (n) modules differents dans la plate-forme API, La 
reference a une methode ou attribut dans le pseudocode est : 
« IE/II> <NCI > < NM/NA» 

La valeur 255 (n) pour le premier multiplet (byte) indiquera, comme 

10 dans le premier mode de realisation, une reference interne au module. 
Cheque valeur diffSrente de 255 indiquera une reference externe a un 
module specifique (100) du tableau de module API de la plate-forme API. 

Apr6s la realisation de la liaison par le lieur (92) hors plate-forme, le 
pseudocode d'un module comporte une entete presentant un tableau de 

15 modules references utilise pour lier le module courant. Ce tableau d 
modules references comprend au plus 255 entries, cheque entr6e 
correspondent a I'identificateur (MID) d'un module API (100). Le premier 
multiplet (byte) d'une reference externe dans le pseudocode sera alors un 
index dans ce tableau. Lors du chargement sur la plate-forme d'un module 

20 non API (67, 66), les numeros d'index associes a des modules API (100) 
seront connus et ainsi chaque premier octet d'une reference externe sera 
remplace par le numdro d'index associ^ au module API refere en utilisant la 
table (102) d'association MID/IMi des modules API (100), Ce remplacement 
est la seule operation de liaison realisee sur la plate-forme specifique, par i 

25 chargeur (68). la table (102) d'association MID/IMi etant utilisee uniquement 
pour realiser cette operation de liaison. 

A titre d'exemple, supposons que dans le pseudocode d'un modul 
de service 'TEST', nous avons la reference d un numero de m6thode 5 du 
numero de classe 7 d'un module API dont I'identificateur (MID) est "FOO". 

30 Supposons de plus que "FOO" est i'identificateur du quatrieme module API 
externe trouve reference dans le module de service 'TEST'. La r6f6rence 
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dans le pseudocode est alors constituee par les trois valeurs suivantes : 3, 
7.5 

Le numero 3 correspond au quatrieme index dans le tableau de 
modules r§fSrenc6s present dans Tentete du module,, venant en t&te du 

5 pseudocode, la valeur de cette entree etant ridentificateur (MID) "FOO". 
Supposons que lors du chargement du module API "FOO, I'index interne 34 
lui ait 6t§ attribu^ sur la plate-forme cible dans la table d'association (102) 
des modules API. Alors, le chargeur (68), a I'aide de la table tf association 
(102) modifie la reference dans le pseudocode du module de service 'TEST" 

10 pour devenir : 34, 7, 5 

Lors de I'execution du pseudocode d'un module, une reference 
externe au module est systematiquement intef5pr6t§e par la machine virtuelle 
comme une entree dans la table de module API. Les modules du tableau de 
module non API restent invisibles les uns des autres ainsi que par rapport 

15 aux modules^..API7 Ce^simple-*dispositif- permet de reproduire I'effet de 
protection I ie^'au concept d'espace de nommage d'une plate-forme classiqu . 
Le simple fait de charger ^un module dans le tableau de module non API le 
rend compldtement inaccessible directement par les autres modules, cr6ant 
ainsi un pare-feu total. 

20 Le tableau (101) de modules API comprend un module specifique 

(105). appele module "API Access" qui comprend une methode native 
(getServicelnstance) dans une classe "gestionnaire d'acces" ou "Access 
Manager" dont le role est de rendre un objet instance de la classe d'entree 
du module de service demand6v Cette methode utilise"* la table (104) 

25 d'association MID/IMi pour connaTtre I'index du module de service demande 
dans le tableau (103). de. modules non-APf puis cr6e une instance de la 
classe d'entree de ce module qui est retoumee par la methode au 
programme principal. La politique de securite preconisee est de faire de la 
classe "Access Manager" une classe protege dont le constructeur et les 

30 methodes sont declarees protegees. De plus, le module ''API Access" (105) 
comprend une protection consistant a interdire que la classe "Access 
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Manager" ait plus d'une instance. Cette methode est reservee au 
programme principal contenu dans le module principal (66). Le module 
principal qui est active en premier cree une instance du module Access 
manager, ce qui lui permet d'utiliser la methode getServicelnstance, mais 

5 interdit d tout autre service de creer une autre instance pour utiliser cett 
methode. Ainsi le module principal pourra creer des instances de services. 

Plusieurs methodes peuvent etre utiiisees pour obtenir cett 
protection consistant a interdire que la classe "Access manager" n'ait qu'une 
seule instance. Le constructeur de la classe peut par exemple bloquer la 

10 demande de creation d'instance lorsqu'il en existe deja une et lance une 
exception de s6curit6. En fonctionnement. Tenvironnement d'execution (RE) 
accede ^ la classe d'entree du module principal (66) et active sa methode 
d'entree (main). Le module principal §tant le premier active, precede a 
rinstallation d'une instance de la classe "Access Manager" du module 

15 Access avant que tout autre service le fasse. 

Afin de permettre a un module de service d'activer un autre module 
de service, cette politique stricte de s^curite peut etre modifiSe en ajoutant S 
la classe "Access Manager" du module API Access (105) des classes 
publiques permettant ^ tout module d'y faire des requfetes. Ces requetes 

20 seront traitees et controlees par {'unique instance creee par le module 
principal. Ces classes publiques comprennent notamment une methode 
statique permettant d'obtenir I'unique instance. Un module ayant acces d 
Tobjet instance de la classe "Access Manager" pourra activer un autre 
module de service et Tutiliser. mais il ne pourra pas referencer directement 

25 ses classes, ses methodes ou ses attributs sans etre repere par la machine 
virtuelle, 6tant donn6 que toute reference externe dans le pseudocode est 
une r6f6rence interne au module ou une reference externe d un module API. 

Pour une realisation simple de cett solution, il est necessaire de ne 
pas avoir de references circulaires parmi les modules API. En consequence, 

30 la fermeture transitive de la relation "ref6re a"("refers to") doit fetre un ordre 
strict partial sur un jeu de modules. II est ainsi possible de concevoir dans le 
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lieur du convertisseur (92) une strategie simple pour lier et produire 
ragencement' deS^ modules -API en traitant en**^prefniet^les elements 
minimums non eneore liesrJI estpossible«de*suivre-la«meme«»strat6gie basee 
sur un ordre paFtiehpour le^elechargementsdes modules^ARIrde telle sorte 

5 que loFS*du>»tel6GhaFgementwd'cjn module"iM«witoujs«ilesiiirinodules auquel^ il se 
refere aient deja ete telecharges et qu'un numero leur aient ete assigne. 
L'assignation de Tindex interne sur la plate-forme cible se fait par le 
chargeur (68) de module en assignant Tindex n-1 a TAPI tfordre n. Un 
module API ne peut referer a un autre API module d'index sup§rieur. 

10 Uutilisation de ce systeme de double tableau de modules (101, 103) 

et de table d'association (102, 104). permet de remplacer facilement un 
m0dule*AP4?tjniquieKpar«plusjeujrs«m0dulesfAP^^^ Le 
remplacement d'un module^ARI^unique>«ipar plusieurs^modules API permet 
d'etendre la ^^platewfopme vARI? avec^.de^*nouveau. moduleSiSu.sans modifier 

15 ['assemblage des modules^dejaxeharges^rsans-Ghanger«lass6Gurit6 offert^ par 
les pare^fea. BiSn^ entenduj^ ces deux modes de^ realisation ne sont pas 
compatibles^ les^modiyles^doiyeRt^etFe^preliesi^sp6oifiquemen^ pour Tun ou 
Tautre des modes de realisation, le pseudocode relatif d un des modes de 
realisation n'etant pas portable sur une plate-forme implementant Tautre 

20 mode de realisation. De plus. Tinterpreteur de la machine virtuelle diff^re 
d'un mode de realisation a Tautre. Dans le premier mode de realisation, la 
machine virtuelle ne manipule qu'un seul tableau et une table d'association : 
le premier multiplet d'une reference sera interprets par la machine virtuelle 
comme une ref§rence=^intenmei^jpour toute^valeur- egale*a -n et^comme une 

25 reference externe ii Tunique module API pour toute valeur diff6rente de n. 
Dans le secomdi^mode^deiirealisatiomf^la ^machine'^virtuieilett^manipule deux 
tableaux et deux tables d'association : le premier multiplet d'une reference 
dans le pseudocode sera interprets par la machine virtuell comme une 
reference interne au module pour toute valeur egale a n et toute valeur 

30 differente de n sera prise directement comme index dans le tableau de 
module API. Dans les deux modes de realisation I'interpreteur de la machine 
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virtuelle comprend des moyens de comparaison du premier multiplet des 
trois multiplets de codage d'une reference a une methode ou a un attribut 
avec une valeur detemnin6e n pour decider s'il s'agit d'une classe interne ou 
externe au module. La num^rotation des modules API peut §tre dSterminde 
5 au moment du chargement pour fixer definitivement et de maniSre trds 
simple les references externes dans le pseudocode. 

Les m&mes m^canismes sont utilises pour manier ies deux types d 
modules, bien que la fagon dont ils sont utilises et la securite procurde 
soient tout a fait differentes. Tout module peut acceder librement aux 
10 modules API puisque leurs classes sont des classes systeme. L'utilisation 
de Tapproche modulaire est utilisee avec les modules services pour procurer 
un pare-feu rigoureux pour proteger ces modules de tout accds direct. 

Le proc6d§ selon I'invention peut etre realist sur tous types d'objet 
portable pr§sentaht de faibies ressources, tel que par exemplie, 16 Kb de 
15 m6moire ROM. 8ko de memoire EEPROM et 256 k de memoire RAM. 

D'autres modifications a la portee de Thomme de metier font 
egalement partie de Tesprit de Tinvention. 
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REVENDICATIONS 

1. PfOcedeide'^eha^gementr^d'applieatiQ^1S1ssur*;u^rsys^^ 
comprenant un environnement d'exeGutioni induamt une imachine virtuelle 

5 comprenant un interpneteurMde^langage de type^^pseudq 

des interfaces de programmation d'application (API), a partir d'une station 
sur laquelle le code source de ('application est ecrit, compile en pseudocode 
par un compilateur (82). verifie par un verificateur (91). converti par un 
convertisseur (92). et charge par un chargeur (93, 68). caract6rise en ce que 

10 - la conversion comprend la realisation de la liaison statique d'une 

plural ite d'ensembles de paquetages destines a etre stock^s dans le meme 
espace nornisuri«le«systerneuembarqu6]Cfappel§§f«nriodiyl^^ attribuant un 
identificateur^d Ghaque module-(MI[D^'; et un-numero de-refi§rence d chaque 
classe (NCI);^a chaqwe^methode (NM) fet.a chaque attribut i(NA) encapsules 

15 dans les classesitdu^moduilef^ 

- la reference a une methode ou un attribut, dans le pseudocode Ii6 
d'un moduley^etant- codeiei^^sur- trois multiplets^constitiuies^parT^un indicateur 
indiquant la ref6rence a une classe interne (II) ou externe (IE) au module, le 
num6ro de la classe (NCI) et soit le numero de la methode (NM) soit le 

20 numero de I'attribut (NA), 

- les modules sont un ou plusieurs modules d'interface de 
programmation d'application comprenant des classes systeme ou des 
modules de services correspondant chacun a une application, une reference 
(IE) a une classe- externe etant-systematiquement«inteppretee^^ machine 

25 virtuelle comme une reference a un module d' interface de programmation 
d'application. 

2^Procede de chargement d'applications sur un systeme embarqu6 
s Ion la revendication 1 . caracterise en ce que le chargement des modules 
sur le systeme embarque comprend la memorisation d'une part d'au moins 
30 un tableau (69. 101, 103) de representation des modules, le num§ro (IMi) 
associe. par le lieur compris entre 0 et n, a un module constituant Tindex 
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dudit module dans le tableau, et d'autre part d'une table (70, 102, 104) 
memorisant rassociation de 1' index du tableau de representation a 
ridentificateur (MID) dudit module, ledit tableau et la table ^tant en m^moire 
programmable non volatile, une reference externa (IE) d un module exteme 
5 dans le pseudocode etant interpretee par I'interpreteur de la machine 
virtuelle comme constituant un index d'acces au module Equivalent a celui 
du tableau des modules. 

3. Precede de chargement d'applications sur un systeme embarque 
selon la revendication 2, caracterise en ce que le chargement comprend la 

10 memorisation, pour chaque module, d'un tableau de representation (TRC) 
de ses classes, comprenant une reference d Tindex de son module et, pour 
chaque classe, un tableau de representation (TRA) des attributs et des 
methodes (TRMe). 

4. Precede de chargement d'applications dans un systeme 
15 embarque selon la revendication 2, caracterise en ce que les modules sont 

references dans un tableau de modules unique, les classes systeme sont 
contenues dans un module API unique, toute reference a une classe externa 
dans le pseudocode differente de n sera interpretee par la machine virtuelle 
comme une r6f6rence audit module API. 

20 5. Precede de chargement d'applications dans un systeme 

embarque selon la revendication 4. caracterise en ce que les classes 6tant 
deciarees publiques. ou en paquetage prive. les attributs et methodes etant 
declares proteges, en paquetage privee ou en classe privSe, la numerotation 
des classes s'effectue suivant I'ordre classes publiques puis classes en 

25 paquetages prives, la numerotation des attributs ou methodes est effectu6e 
par le convertisseur (92) suivant I'ordre attribut ou methode public, protEg§, 
en paquetage prive et en classe privee. 

6, Procede de chargement d'applications sur un systeme embarqu6 
selon la revendication 2, caracterise en ce que les classes systdme sont 

30 contenues dans plusieurs modules API chargeables separement, le 
chargeur (68) maintient dans la memoire non volatile programmable deux 
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tableaux de representation des modules et deux tables d'association MID/lmi 
correspondantes. Tun pour les modules API et I'autre pour les modules non- 
API, le chargeur chargeant les modules dans^ run des deux tableaux selon la 
nature du module specifie dans Tentete de celui-ci, toute reference exteme 
5 d'un module du tableau de module-etant interpretee comme une ref6rence a 
rindex du module API. 

7. Proced6 de chargement d'applications sur un systeme embarque 
selon la revendication 6, caracterise en ce que la liaison statique d*un 
module est effectuee de telle sorte que la reference a une classe exteme a 

10 un module non API dans le pseudocode intermediaire est un index dans un 
tableau de I'entete du module, dont chaque entree est un identificateur 
(MIDrd'un module-^ARIVefeFenc^r Je charg module sur la plate- 

forme cible comprenant le remplacement de ladite reference par le numero 
de rindex du module API obtenu a partir de T identificateur (MID) de la table 

15 d'association MID/IMi^des modules API. 

8. Systeme embarque comprenant une machine virtuelle et une 
plate-forme API incluant des interfaces de programmation d'application, une 
memoire non volatile fixe, une memoire non volatile programmable ou 
modifiable, et une memoire vive, caracterise en ce que la memoire non 

20 volatile programmable comprend au moins un module API comprenant des 
classes systeme et des modules de services, au moins un tableau de 
representation des modules (TRM), dans lequel les modules sont index6s et 
une table (70, 104) associant Tindex (IM) d'un module du tableau de 
representation a Tidentificateur (MID) dudit module, chaque module 

25 comprenant un tableau de representation des classes (TRC), dans lequel 
les classes sont indexees et dans^^^lequel chaque classe presente une 
reference ^ rindex (IM) de son module, chaque classe comprenant un 
tableau de representation des attributs (TRA) et d s methodes (TRMe), 
dans lesquels les attributs et methodes sont index's, la reference a une 

30 methode ou un attribut etant codee sur au moins trois multiplets (bytes) 
correspondant a une reference a une classe interne (II) ou externe (IE) au 
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module, une reference externe au module constituant Tindex du modul API 
dans le tableau de module, un numero de classe (NCI) correspondant a 
rindex de la classe dans la table de representation des classes du module, 
et un numero de methode (NM) ou d'attribut (NA) correspondant a I'index de 
5 la methode ou de Tattribut dans le tableau de representation des m^thodes 
ou attributs de, la classe du module. 

9. Systeme embarque selon la revendication 8, caracterise en ce 
qu'il comporte des moyens de comparaison du premier multiple! des trois 
multiplets de codage de reference a une methode ou a un attribut avec une 

10 valeur determinee n pour decider s'il s'agit d'une classe interne ou externe. 

10. Systeme embarque selon la revendication 8, caracterisd en ce 
qu'il comprend un module principal comprenant le programme principal du 
systeme. 

11. Systeme embarque selon la revendication 8. caracteris6 en ce 
15 que les classes sent indexees suivant I'ordre classes publiques puis classes 

en paquetages prives, et les attributs ou mSthodes suivant I'ordre attribut ou 
methode public, protege, en paquetage prive et en classe privee. 

12. Systdme embarque selon la revendication 11, caracterise en ce 
que la memoire non volatile programmable comprend plusieurs modules API 

20 comprenant des classes systeme, deux tableaux de representation (101, 
103) des modules, Tun pour les modules API et Tautre pour les modules 
non-API, et le module principal, et deux tables (102, 104) d'association 
MID/IMi correspondant chacune a un tableau de representation des 
modules. 

25 13. Systeme embarque selon la revendication 10, caracterise en ce 

qu'il comprend une classe gestionnaire d'acces "Access manager" d'un 
module API (105) comprenant une m6thode permettant de creer un 
instance d'un module de service, par I'intermediaire du module principal, 
ladit classe pres ntant une protection lui interdisant d'avoir plus d'une 

30 instance. 
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14. Precede d' execution d'une application d'un systeme embarque 
multi-application, comprenant un environnement d'execution incluant une 
machine virtuelle comprenant^ un interpr6teur de- langage de type 
pseudocode intermediaire, et des interfaces de programmation d'application 

5 (API), caracterise en ce que, lors de Texecution du pseudocode 
intermediaire rfun module de service, correspondant a une application, 
referencee dans un tableau de module, la reference a une methode ou un 
attribut dans le pseudocode, codee sur au moins trois multiplets (bytes) 
correspondant a une reference a une classe interne (II) ou externe (IE) au 

10 module, un numero de classe (NCI) et un numero de m6thode (NM) ou 
d'attribut (NA). une reference externe au module est interpretee par la 
machine virtuellercomme uneceference a riiidex d'un module API du tableau 
du ou des modules API . 

15? Precede ^'execution d'une application d'un systeme embarque 

15 multi-application^sselonHa revendieation 14, caracterisd^ en ce que, sur 
reception d'une demande d'executidn d'uh module-de service pr6sentant un 
identifieatei!jr^^(MID)Vrehvir0nnement d'execution accede-^ la classe d'entr§e 
d'un module principal comprenant le programme principal du systeme, le 
module principal installe une instance d'une classe sp6ciale "Access 

20 Manager" d'un module API, gerant Tacces a un module de service, et utilise 
une methode de cette classe permettant de creer une instance de la classe 
d'entree du module de service demandee. par rinterm6diaire d'une table 
d'association de I'identificateur a Tindex du module dans un tableau dans 
lequel le module est reference. I'instance etant retoumfee par la methode au 

25 programme principal. 
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